Code Review

This pull request introduces a webhookHealthy field to the ProviderSyncStatus interface and parses it from the sync status payload (supporting both camelCase and snake_case). This field is used to prevent soft degradation of Slack sync (e.g., when the sync watermark is stale but webhooks are actually healthy), ensuring that Slack writeback is not unnecessarily skipped. Comprehensive unit tests have been added to verify this behavior. I have no feedback to provide as there are no review comments.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f424c28f78

Heads-up on branch ownership: we collided — I had pushed a narrower fix here (f424c28) and this branch was force-pushed over it. No complaint, your version is better and I'm not pushing over it. Two findings from reviewing it against my copy, one of them a proven bug.

Your veto is better than mine — keep it

I put the veto inside slackSyncStatusResult; you put it in #slackFreshness() with slackGateBypassedByWebhookHealth + an info log. Yours is observable where mine was silent, and the soft-only/hard-still-degrades semantics match. Yours also does the thing I could only suggest in #94: decoupling the ask instructions from thread existence and routing Slack → GitHub → operator-visible error, so a degraded Slack no longer silently strips the agent's ability to ask. That's the deeper fix.

Proven bug: the hasProviderSyncFreshness change drops real freshness

Adding webhookHealthy to hasProviderSyncFreshness changes source selection. A wrapper carrying only webhook health now qualifies as the freshness-bearing candidate and wins candidates.find(hasProviderSyncFreshness), so the actual watermark on a nested connection is discarded.

Repro against this branch:

fake.getSyncStatus = async () => ({
  webhookHealthy: false,                                            // wrapper: health only, no freshness
  connections: [{ provider: 'slack', lastEventAt: '2026-06-06T12:05:00.000Z' }],  // real, stale watermark
})
await mount.getSyncStatus('slack')
// RESULT: {"provider":"slack","webhookHealthy":false}   <-- lastEventAt GONE

Consequence: a genuinely dead Slack (webhookHealthy: false + stale watermark) normalizes to no lastEventAt, no lagSeconds, no status → slackSyncStatusResult returns { known: false, degraded: false } → not degraded. Factory then keeps writeback pointed at a Slack nobody reads: the question posts, no reply ever arrives, and the agent waits. That's the inverse of the failure this PR fixes, and it's the case the gate exists for.

Also still live: the Codex P2 (source-only read)

webhookHealthy: booleanField(source, ...) at relayfile-cloud-mount-client.ts:504 still reads only from source. The hasProviderSyncFreshness change masks Codex's specific example (the wrapper now wins), but by dropping the watermark rather than reading both — so the flag and the freshness can still disagree about which object they came from.

Suggested fix — one change addresses both

Revert the hasProviderSyncFreshness addition (let freshness selection stay freshness-based), and read the flag across candidates instead:

// `source` is picked for *freshness*, so webhook health can sit on a different candidate.
// An explicit `false` from any candidate wins: a wrong `true` keeps writeback pointed at a
// Slack nobody reads, which is the worse failure.
const webhookHealthySignals = [source, ...candidates]
  .map((c) => booleanField(c, 'webhookHealthy') ?? booleanField(c, 'webhook_healthy'))
  .filter((v): v is boolean => v !== undefined)
// ...
webhookHealthy: webhookHealthySignals.includes(false) ? false : webhookHealthySignals[0],

This keeps the stale watermark and sees the wrapper's flag, so the two can't disagree. Verified RED-before-green on my copy for both Codex's shape and the drop-freshness shape above.

Happy to push these two onto this branch if you'd rather not context-switch — say the word and I'll rebase onto your head rather than over it.

Field context, if useful

This is what a live Slack reports today (AgentWorkforce/cloud#2666): lastEventAt only advances on sync events and the schedule is unregistered, so it reads 6wk stale while webhooks deliver in ~8s (verified with a live post). webhookHealthy: true was correct throughout — hence this PR. Reproduced end-to-end on published 0.1.19 before the fix: relayed#48 (deliberately unanswerable from the repo) → agent never told it could ask → 30min stall, zero commits, no PR (timed out waiting for spawned agents to exit). Details in #94.